cool!!!

@ern @ottenhoff I think we should merge this into 25.x. I've fixed all the unit tests and made some a11y fixes that the tests caught.

agree i like it

This needs to go in before anybody else adds significant webcomponents PRs.

strange that the cypress build fails but the other 2 maven builds pass!

remove the since origin/master part of lerna test

@ottenhoff Are you sure about that? that switch is pretty nice. It tests the modified files and all the packages that depend on it. Do we want to test everything everytime?

@ottenhoff Are you sure about that? that switch is pretty nice. It tests the modified files and all the packages that depend on it. Do we want to test everything everytime?

Yes, I think it's the job of CI to just test everything. Locally it makes sense if you want a quick test

Okay, this stuff's working now. It uses Playwright to download Chromium and runs the tests in parallel. Takes about 30 seconds. If you're working on a particular component, you can still run tests just for that that component and its dependant packages. Best of both world's hopefully.

This PR is consistently failing an Assignments cypress test in Grader.

http://localhost:8080/direct/assignment/setGrade.json POST returns a 400 when setting a letter grade on a student assignment

I am totally amiss as to why this would fail the cypress tests. The grader source is touched, but very superficially, just removing some "same-origin" options from the fetch requests (default anyway) and uncoupling the grader from the portal object a bit by using getSiteId instead of portal.siteId. This PR also does not touch AssignmentEntityProvider at all.

I just did a full master rebuild and ran the latest cypress tests, and it fails, so whatever I've done in this PR, the Cypress tests were already failing

you dont see a stacktrace locally when setting a letter grade on a student in Assignments?

@ottenhoff Do you mean in the cypress output, or when actually directly using Sakai?

just replicate the cypress test: create an assignment using letter grades and try to grade a student in the Grader

@ottenhoff works fine for me.

Easy to replicate the issue:

08-Apr-2025 10:58:12.965 WARN [http-nio-9080-exec-6] o.s.a.e.AssignmentEntityProvider.<init> The property "prop_new_assignment_add_to_gradebook" is null for the assignment feed
08-Apr-2025 10:58:13.281 INFO [http-nio-9080-exec-2] o.s.e.u.s.DirectServlet.dispatch Could not process entity: /assignment (400)[org.sakaiproject.entitybroker.exception.EntityException: You need to supply the courseId, gradableId, studentId and grade]: You need to supply the courseId, gradableId, studentId and grade (rethrown)

getSiteId is coming back empty inside the cypress test

export const getUserId = () => window.top?.portal?.user?.id || "";
export const getSiteId = () => window.top?.portal?.siteId || "";

I think you're basically saying here that Sakai MUST be the top window and absolutely can't be framed. this is a change from the previous use of portal.siteId

@ottenhoff They're all the same thing. top is safe because it will always refer to the topmost window in the current hierarchy, which might just be window, or it might be window.parent.

Ah, hang on. I get you. I just came back from the pub, so the noggin is on the go slow.

so, window?.portal?.siteId || window?.top?.portal?.siteId || "" would do the trick?

@ottenhoff I still can't reproduce that error with letter grades. I've rebuild all the code, twice now, and still no joy.

@ottenhoff Cypress passes now :) Was it because all the cypress stuff runs in frames? The only significant change in this PR was moving to getSiteId which would have tried the topmost window.

We obviously don't run any dependencies on portal-utils in frames at the moment. I'm glad Cypress caught that.

@ottenhoff Can you approve it? Are we happy to go forward? If it causes issues with builds I can just take it out of the pom with another JIRA, but it seems pretty good now. 30 seconds of ui tests, plus the linting etc.